Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

How Cloud Computing Can Change App Development?

RickyVPhilip — Fri, 10 Sep 2021 04:18:00 GMT

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, migration is not enough. To overcome the modern challenges and step ahead of the tight competition, tech enterprises both large and small need a more sophisticated approach to cloud-based app development. One of the best advantages is that it encapsulates everything from development to deployment; everything from how we design, build and manage software, all under one roof. If your enterprise is still not completely aware of the benefits of the cloud in application development, let us give you a walk-through, so that you understand the advantages and utilize the cloud.

The Need For Cloud Computing In Application Development

Every application nowadays consists of data and processing logic stored as code and needs an efficient storage space to be run effectively. Users of cloud-based applications interact through a mobile application downloaded from Playstore or Appstore or can even interact from the browser, and the data processing takes place on the remote server base and is handled with the help of an API. In this case, a user’s device serves only as of the input device and does not host the majority of processes therefore the applications perform efficiently and without any. Besides, a cloud-native software or application makes digital operations more streamlined and implements greater flexibility for businesses of any size.

Enterprises would need to align their applications, so as to utilize the cloud service models that it offers. Some of the typical benefits are listed below:

Cost-effective: Cloud computing eradicates the capital expense of buying and maintaining hardware and software. As mentioned earlier both hardware and software can be accessed over the internet through the service models. It also eliminates the cost of running racks of servers, on-site data centers, electricity for power and cooling, IT experts for managing the infrastructure, and much more. The service providers such as Amazon AWS or Microsoft Azure provide services as pay per usage, the infrastructure is also not purchased thus lowering maintenance.

Enhanced Speed: The cloud computing services are given by service providers on the customer's demand, therefore even fast amounts of computing resources, platforms, or tools can be provisioned in a few minutes. This means with just a few mouse clicks unlimited storage space can be accessed, cloud development platforms can be utilized and backup maintained. This gives companies and enterprises a lot of flexibility to manage operations; thus seamlessly takes the pressure off of the IT team and infrastructure maintenance team.

Better Productivity: There are several demands for on-site datacenters that normally range from continuous racking and stacking device setup as well as software patching, and other time-consuming IT management processes. Cloud computing eliminates the requirement for many of these tasks therefore the IT teams can spend more time on solving important business goals.

Increased Performance: The most significant cloud computing services are operated on a worldwide network of reliable data centers which are frequently upgraded to the most advanced generation of fast and efficient computing. This suggests various advantages over an individual corporate data center, including diminished network latency for applications and bigger economies of scale.

Security: Cloud service providers such as Amazon AWS and Google Azure offer a broad sense of policies, technologies, and controls that strengthen the security posture overall. This helps enterprises with huge resources to protect their data allocations and infrastructure from upcoming threats and malware.

More Reasons To Opt For Cloud-Based Web Development

Further, before developing an appropriate cloud-based application, developers can choose from the three cloud service models various services, and use cases. This makes it much easier for developers as the cloud itself provides the tools, platforms, hosting services, and much more to develop applications. Few of the predefined services that cloud provide developers are listed below:

Readymade Software (RMS): It offers predefined codes or low code development strategies for standard software such as email systems, payroll applications, ERP systems, etc.

Web Hosting (WH): Hosting and maintaining an organizational website.

Data Storage (DS): Cloud provides unlimited storage of any kind for organizational data or backup and recovery, archiving, document management, and much more

Network Server (NS): An efficient and reliable computer server that is used for seamlessly storing and running databases, mail, or business applications.

Computer Network (CN): Cloud also offers a computer network that can be efficiently used for establishing an intranet and/or extranet.

Conclusion

Cloud computing is a continuously evolving technology that is currently being increasingly adopted because of the multiple benefits and use cases. Prominent cloud technology leaders, such as Google, Amazon, and Microsoft have contributed their leadership in developing more advanced innovations in cloud computing. There are several technological groups out there, such as the Cloud Security Alliance or the Open Cloud Consortium, which was formed to explore the opportunities offered by cloud computing. From cloud deployment models to cloud service models, there is always something about the cloud that pushes organizations to adopt cloud and enhance their operations.

7 Tricks to Stay Focused While Studying

DorothyPWatkin — Fri, 21 May 2021 13:19:00 GMT

So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cute puppy photos for half an hour. Then you come across DIY dorm décor on Tumblr and spend another half an hour looking at those. Then you start thinking about your own dorm and start rearranging furniture and organizing your closet. Next thing you know, it’s 2 am and you’re tired so you just tell yourself you’ll wake up early to finish the rest of your studying (and we all know how that story ends).

I went through this cycle for the first couple of months when I started my first semester of college. After I saw my grades plummeting, I decided to put those days behind me and start taking control of my studying habits by following these simple tricks to increase my focus. Everyone is different so maybe not all 7 will help you, but try to tackle a few to see if they help you stay focused!

1. Put the phone out of sight

My cell phone was my biggest distraction. Even when I put it on silent, I would still pick it up every five minutes to check if I had a notification or scroll through social media. I started to realize that the only times I stayed focused on my studying were when my phone was charging on the other side of my dorm. I couldn’t see it and I couldn’t hear it, so I didn’t think about it. My mind shifted its focus from my phone to my notes. So put your phone out of sight, because the expression “Out of sight, out of mind” is so very true in this case!

2. Use a timer

This is very useful for students who study from a laptop or tablet and often get distracted by going on YouTube, Facebook, etc. By using this method, I finished my work 2 hours earlier than before! Open your device’s clock or timer app/program and set the timer to the amount of time that you believe is a good amount to study for one particular class. Once you start the timer, you can’t change it! Leave the timer open and visible while you study. This helps minimize distractions by reminding yourself you only have X minutes left to finish your studying, so it isn’t a good idea to spend 20 of them on Facebook. Try to study everything before the timer runs out. Once the timer runs out you have to move on to the material for the next class, even if you’re not finished. When you’ve timed yourself for the rest of your classes, go back to the one(s) you didn’t finish and repeat.

3. Keep yourself alert

Sometimes we lose focus simply because the material bores us to sleep or we’re just too tired to pay attention to what we’re studying. Keep yourself alert by eating a snack (granola bar, fruit, or nuts), taking a power nap (no more than 45 minutes), having a cup of coffee, or even exercising. If these methods don’t work, use the old-fashioned method of splashing cold water on your face!

4. Use rewards

Only you know the best way to reward yourself. Whether it’s ice cream, partying, or going to the movies with your friends, make this a reward for finishing your work. A good idea is to create a reward that is already available to you before you start studying, something that is “within reach” as they say. For example, I LOVE Oreo Thins. I bought a pack of Oreo Thins and kept it in my dorm, but I only allowed myself to have some after I finished my tasks. Knowing that the Oreos were already there waiting for me, I was more willing to stay focused on what I had to study.

5. Break it up

Don’t try to study everything for one class for 4 hours straight. Break it up into segments, with short 15 minute breaks in between. Use these 15 minutes to take a power nap, check your phone, read your favorite book, or even go for a walk. By doing this, you avoid burnout and refresh your mind so it can stay on track when you get back to work. It’s also a good time to reward yourself if you set little studying goals to be completed before each break!

6. Don’t study with friends

Once you find your perfect study spot, try to refrain from inviting friends to study with you there. When I tried to study with friends, I thought we would be productive with double or triple the brain power, but the anticipated study session just turned into chat time. Instead, study on your own and then meet up with friends to test each other on what you studied. Testing your knowledge before a test will give you an extra memory boost, and your friends can test you in a way you might not have thought about! This method definitely helped me during finals week.

7. Play focusing music

Focusing music is essentially non-distracting “background” music and doesn’t have lyrics. This may not work for everyone but it works for me because when I study in complete silence, I start thinking about things other than what I’m studying. You can listen to alpha wave music designed for staying concentrated and increasing brain power, or you can listen to other kinds! I listen to a cinematic background music playlist on YouTube when I study. It kinda makes me feel like I’m in a movie and the fate of our world depends on me passing my test tomorrow, so I have no other choice but to focus!

Hopefully some, if not all, of these tricks help you while you study and eventually improve your grades! What are some tricks that you use to keep yourself focused?

Top 10 mistakes in Use Case Modelling

Trividh Patel, CBAP — Mon, 11 Jan 2016 03:10:00 GMT

Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders.

1. Naming the actors using the job titles

Job titles and actor names are two different things and often cause confusion. This is because two different users, with different job titles and organizational responsibilities, may have to use the system as a same actor; for example, a supervisor can have access to and use the functionality used by his/her subordinate. Actor is a role that is with respect to the system as opposed to a job title which a role with respect to the organization. Job titles may typically determine user types. Remember, job titles of people may change but the roles they play would remain relatively stable.

2. Creating only the use case diagrams

Use case diagrams only provides summary of the relationship between the actors and the use cases. Can we tell what a system does basis only the use case diagram? No; a system cannot be built just based on the use case diagrams. We need detailed use case descriptions to design and build the system.

3. Not capturing enough details

Too much detail can obscure the flow of the use case and too less can make it really meaningless. “How detailed a use case should be?” In as much detail as possible and in as much detail that is required to make them unambiguous to describe what the system must do. Focus on what is important and continue to add details till all the stakeholders are satisfied.

4. Describing everything a system does in a use case

It is important to identify all the use cases and describe them so that everyone understands who uses the system and what goals they achieve by using it. This is particularly important when the user-system interaction is complex and detailing the system behaviour is essential to develop and test the system. However, if we blindly do this for all the use cases than we are just increasing the documentation and subsequent time required for reviews and sign-off, without delivering any additional value to the project and its stakeholders. So, for cases where the user-system interaction is simple, use cases are not required to be fully described. In such cases, a simple use case description supplemented with declarative requirements and other models may be sufficient to understand what needs to be done.

5. Performing functional decomposition

BA teams typically tend to group functional requirements, or break them in form of functions or menu-items and identify them as use cases. What they don’t understand is, high-level use cases cannot be decomposed into lower-level use cases and also use cases cannot call, communicate, get linked or sequenced with other use cases. This approach is most common of all mistakes made while identifying and describing use cases. Let us try to understand this with an example.

What use cases will you identify for a system say, a car? The adjoining diagram shows the use cases identified using this approach. Here, all the necessary functions (menu-items!) are available to a ‘Car Driver’ (actor) to drive a ‘Car’. With this approach, are we answering what the ‘Car Driver’ will do to drive (actual goal) the ‘Car’? None of the use case actually describes the way ‘Car Driver’ will interact with (or use) the ‘Car’ to drive it without linking or sequencing them. The system appears as a large set of disconnected functions. To identify the right use cases, always keep in mind the goal that the actor wants to achieve by using the system. Each use case must be complete to provide value to at least one of its actors.

6. Writing perfect use cases

There is no such thing as perfect use cases. Many BA teams waste their efforts in trying to create perfect use cases. The focus should be on making use cases as good as required for facilitating communication amongst stakeholders to achieve shared understanding of requirements and moving to system design, development and testing.

7. Detailing use cases with the CRUD behaviour

Although it is not technically wrong but detailing uses cases with CRUD (create, retrieve, update, delete) behaviour, for example maintaining information for administrative systems, is a waste as it is mere repetition of declarative form of requirements specifications. Use cases with the CRUD behaviour don’t add much value to ensure that the system is doing right, particularly when information can be added in any sequence without any dependency. Except for data validation rules and specific fields to be entered, the use cases with the CRUD behaviour become repetitive. These efforts can be used for detailing use cases with real flow of events.

8. Using the use case model to design the system

Many times, BA teams also document how a system should handle certain functionality internally as part of use case descriptions. By specifying such functionality we are imposing constraints on the development team to design the system in a specific way. Many would argue that “it is a BA’s job to think for all scenarios and provide a solution” but we forget that the real purpose of a use case is to describe what system does to fulfil the goals of the actor and by mentioning constraints inside a use case we are just making this behaviour difficult to understand. So, anything that must be handled in a certain way should only be described in the use cases and all other things should be left out for the developers to decide. Constraints can be captured in other specifications and traced back to the use cases so that they are not forgotten during the system design. Use case model must never be used to design the system. Use cases describe what the stakeholders want the system to do and not how the system implements the functionality.

9. Describing things outside scope of system

Use case model captures the interactions of actors and the system and describes what the system does to fulfil actor goals. Outside system boundary a stakeholder (identified as an actor) may interact with another stakeholder (who may be identified as another actor); to support the business process. If this interaction (business process) is not supported by the system, it should not be captured in the use case model. Use cases can be used to capture business processes as “business use cases” with actors outside the business boundary. Never mix systems use cases and business use cases.

10. Misusing the use case relationships

BA teams also spend lot of time structuring the use case model, with use case relationships such as include, extend and generalization, assuming that such structure is required in every use case model or required for the system’s architecture. BA teams typically useinclude relationship to break a use case into smaller use cases by performing functional decomposition of the system. The result is that none of the use cases by themselves provide any real value as it becomes very hard to see what a system does. Using use case relationships without understanding their real purpose just results into a confusing use case model.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

Use cases and statecharts notation design

Dr. Mohamed El-Attar — Tue, 21 May 2013 04:39:00 GMT

Dear Fellow Business Analysts,

I have created two surveys as part of my research work. The surveys elicits your opinion on some notation designs related to use cases and statecharts. Both surveys will require no more than 15 minutes of your time. Your cooperation is greatly appreciated. The links to the surveys are as follows:

Use Cases survey

http://www.MrFixItHat.com/usecasesurvey.php

Statecharts survey

http://www.MrFixItHat.com/statechart.php

Regards,

Dr. Mohamed El-Attar

The Need for a Recipe

Dahlia Biazid — Thu, 13 Sep 2012 07:50:00 GMT

Everyone knows what use cases are and their use in the software requirements process. We all know there are many ways to write them: logical, physical, to describe a manual procedure or an automated procedure. The purpose of State Diagrams is well-known to everyone in the field. They help us define the transitional lifecycle of an object moving and manipulated on within a system. Data dictionaries are important to describe the elements of each data entity or class. And so on.

It is like a toolbox to choose from. I could use the hammer to bang on a nail (its original use), or to open something (an innovative use). In my requirements projects (or rather sub-projects form software development for that matter), I can use any or all of these techniques to analyze the system at hand. The question is when? What is the best strategy to employ these tools and get results most efficiently and effectively?

Nevertheless, this question did not seem answerable; even worse, it was not even asked! Instead, I looked around for a sample deliverable or a template to follow, with the hope that they would give me a picture to visualize and help me put the pieces together; and hopefully relieve me from the need to have a strategy. The tactic worked to an extent, but not completely. I still did not know for sure which step to make at each time I went to see the client or sit to think about the requirements plan. Only until the project was complete was I able to see the picture. So naturally, I took longer than I should to complete requirements; and the results were not as satisfactory as I as well as everybody involved wished for.

What was missing was the method, the strategy, the cunning of a chef who knows which ingredient to add and the exact timing and portion. What was really missing - and seems to be still missing - is the "recipe".